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(57) Abstract: Providing information 
to a communications device includes 
determining the relevance of an event to 
a user based on service choices of the user 
and, if the event is relevant to the user, 
determining the relevance of information 
sources to the event, the information sources 
including at least data indicating a real-time 
status of the user, and determining whether 
to send information about the event to the 
user based on the information sources. 
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PROVIDING INFORMATION TO A COMMUNICATIONS DEVICE 

BACKGROUND 

This invention relates to providing information to a 
communications device . 

A communications device such as a pager, a cellular 
phone,, a personal digital assistant, or a telephone may 
periodically receive information from a remote source such as 
a web server connected to the Internet. A user of the 
communications device can indicate preferences to the remote 
source such as when and what types of information to send to 
the communications device. For example, using Yahoo! To Go, 
the user may set up a schedule indicating the time of day and 
day of the week to be notified of a preferred city's weather 
forecast, personal horoscope, and preferred companies' stock 
prices. Schedules on these remote sources are static; the 
remote sources send the indicated information to the user at 
the indicated time(s) until the service is terminated. 

DESCRIPTION OF DRAWINGS 
FIG. 1 is a block diagram of a networked communications 
system. 
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FIG. 2 is a block diagram of a context interpretation 
engine in accordance with an embodiment of the invention. 

FIG. 3 is a flowchart showing the operation of the 
context interpretation engine of FIG. 2 in accordance with an 
embodiment of the invention. 

DESCRIPTION 

Referring to FIG. 1, a system 100 includes a desktop 
computer 102 configured to connect to a server 104 via an 
Internet service provider (ISP) 106 and an Internet 108. A 
user of the desktop computer 102 may register with the server 
104 and indicate to the server 104, using a specific user 
identification code that uniquely identifies the user, what 
services the user wishes to receive on a communications device 
110. The user can register with the server 104 using the 
desktop computer 102 or any device configured to connect to 
the Internet 108 or other network, e.g., intranet or extranet, 
connected to the server 104. These services can include what 
types of information the user wants to receive, when the user 
wants to receive the information, and what communications 
device (s) 110 can receive the information. Such 
communications devices 100 include cellular phones, pagers, 
computers, personal digital assistants, and other wireless 
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communications devices. Before the server 104 (or hardware 
and/or software mechanism associated with the server 104) 
sends any information to one or more of the user's 
communications devices 110, a context interpretation engine 
(CIE) 112 helps determine the context of the user. By ; 
considering context before sending information, the user 
receives individualized information relevant to his/her 
habits, lifestyle, and real-time status. 

Also referring to FIG. 2, the CIE 112 includes an event 
listener 200, a rules engine 208, and a context aggregator 212 
to help determine the user's context. The event listener 200 
monitors and detects certain events of potential relevance to 
users and forwards the events to the context aggregator 212. 
The context aggregator 212 derives a user context for each 
event provided to it by the event listener 200 using rules 206 

(through the rules engine 208), context information sources 

i 

202, and a user profile 204, each organized in one or more 
collections of data, e.g., databases 114 and 116, included in 
or accessible by the server 104 and described in more detail 
below. 

Essentially, the current (real-time) and future plans of 
the user define a user's context. Specifically, context may 


include information compiled from the context information 
sources 202 related to the user's: 

• location, e.g., latitude and longitude, zip code, 
wireless cell site, elevation, and time zone; 

5 • mobility status, e.g., stationary or en route to a 

specific destination, speed, and direction; 

• current activity, e.g., type (at home, at desk, at 
a meeting, in a car, on an airplane, on a train, 
walking, etc.), duration, people involved, activity 

10 site (home, desk, conference room, hotel, freeway, 

airport, etc.), and subject matter; 

• timeline of future activities, e.g., type, 
duration, people involved, activity site, and 
subject matter; 

15 • top n (prioritized) items in a to-do list; 

• prioritized contact list; and 

• event priority, e.g., importance (high, medium, or 
low) and urgency (high, medium, or low) . 

This list of context characteristics is not all-inclusive. 
20 The context information sources 202 are adapted to allow 
context characteristics to be added or deleted from 
consideration. 
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Some or all of this information can include attribute 
qualifiers of inferred information that enable the CIE 112 to 
further define the information (and thus the user's context): 

• accuracy, e.g., a global positioning satellite 
(GPS) based location data is coarse whereas 
differential GPS location data is precise; 

• confidence (duration and source of information 
determine accuracy) , e.g., speed and direction must 
stay steady for a specific duration before they are 
deemed accurate; 

• disposition, e.g., cannot be disturbed and 
available through which communication device (s) ; 

• importance level, e.g., associating an importance 
to an event by evaluating the source of the event 
(spouse, boss, peer, child, airline, etc.); and 

j • urgency level, e.g., associating an urgency to an 

i 

event by evaluating source of the event and impact 

of the event (flight delayed, change in driving 

times, meeting moved up, etc.). 

Also referring to FIG. 3, the CIE 112 determines the 

relevance of an event to registered users and the event's 

relation to each user's context in a process 300. The CIE 

112, using the event listener 200, rules engine 208, and 
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context aggregator 212 , implements the process 300 with a 
software mechanism, i.e., algorithms, though one or more 
hardware mechanisms may accomplish the same results. 
Additionally, the server 104 may include more than one CIE 112 
5 to help determine context. 

Before the CIE 112 begins determining the user's context 
for an event, however, the event listener 200 monitors and 
detects (301) events. The event listener 200 can monitor and 
detect (301) these events from any information source it is 

10 adapted to communicate with, including information sources on 
the Internet 108, intranets, and extranets. For example, the 
event listener 200 can register with various information 
sources and act as a listener for events, meaning it can 
receive notification from the information sources when the 

15 information source adds, deletes, or modifies items (events) . 
The event listener 200 may register to receive notification of 
all events the information source maintains/controls/detects 
or just certain categories of events. Events that the event 
listener 200 may monitor and detect (301) include: 

20 • weather conditions; 

• traffic conditions; 

• news; 

• sports scores; 
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• travel information, e.g., flight information and 
directions; 

• receipt of electronic mail (email) ; 

• auction status; 

• reminders; 

• calendar changes; 

• stock prices; and 

• horoscope. 

This list of events is not all-inclusive. The event listener 
200 is adapted to allow events to be added, altered, or 
deleted from monitoring and detection. 

Once the event listener 200 detects (301) an event, the 
context aggregator 212 receives (302) notice of the event 
including a description of the event and a user identification 
code. The server 104 provides the user identification code to 

the event listener 200 and may provide it directly to the 

1 

context aggregator 212 rather than through the event listener 
200. 

The context aggregator 212 determines (304) the relevance 

of the event to the user's service choices as indicated in the 

user profile 204. The user profile 204 contains profile 

information on registered users, usually information provided 

by the users. Such information can include a user's: 
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name ; 

home information, e.g., mailing address, telephone 
number (s), fax number (s), and email address (es) ; 
work information, e.g., mailing address, telephone 
number (s), fax number (s), and email address (es); 
communications devices; 

historical (previous) data, e.g., user interaction 
logs; 

contacts, e.g., names, addresses, telephone 
numbers, email addresses, birthdays, and 
anniversaries ; 

travel profile, e.g., route taken from home to 

work, seating preference, special service required, 

meal preferences, passport information, frequent 

flier information including airline and 

identification code, car rental information 

including car model/size preference and quantity, 

and hotel information including hotel chain and 

hotel chain identification code; 

birthday/astrological information; 

news profile, e.g., preferred city(s), preferred 

subject (s) (world, politics, sports, etc.), and 

preferred sports and sports teams; 
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• finance profile, e.g., preferred companies and 
stock ticker company codes; and 

• preferred times to be notified of certain events. 
This list is not exhaustive. The user profile 204 is adapted 
to allow information to be added, altered, or deleted.. 

For example, if the event relates to the closing stock price 

of company X, the event is not relevant to a user interested 

in closing stock prices for only companies Y and Z, so the 

process 300 ends (306) . Similarly, if the event relates to 

the weather conditions of a certain city but the user's 

calendar indicates that the user will not arrive in that city 

for a meeting for another three days, the context aggregator 

212 can determine that the event is not relevant to the user 

and the process 300 ends (306) . If, alternatively, the 

closing stock price of company X or the weather information is 

relevant to the user, the process 300 continues _ 

If the server 104 includes more than one CIE 112, the 

server 104 may determine (310) which CIE 112 to send certain 

user identification codes to based on the types of events or 

classes of users that each CIE 112 is configured to handle. . 

In that case, the context aggregator 212 receives (302) only 

the user identification code and avoids (312) determining 

(304) whether the event is relevant to the user, as the event 
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is relevant to all users considered by that CIE 112. The 
context aggregator 212 may not receive (302) the user 
identification code if it has a database of or otherwise has 
access to all the user identification codes related to a 
5 particular event type. 

Knowing that the event has bearing on the user' s service 
choices, the context aggregator 212 considers the context 
information sources 202, the user profile 204, and the rules 
206 to formulate a context for the user given the event. The 

10 rules 206 include a number of rules sets, each rules set 

including a number of rules corresponding to a certain type of 
event, such as the types listed above. The context aggregator 
212 determines which rules set applies to the event and 
informs the rules engine 208 which rules set to use. The 

15 rules engine 208 determines (308) what context information 

sources 202 relate to the event using the rules set and relay 
that information to the context aggregator 212. Using the 
rules 206 allows the context aggregator 212 to consider all 
relevant context information sources 202, infer links between 

20 various context information sources 202 based on the user 
profile 204, and generally provide the flexibility to use 
heuristics (rules drawn from past experience) . 
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The rules engine 208 determines (308) which context 
information sources 202 the context aggregator 212 should 
consider in deriving the user's context for each event. The 
rules engine 208 is configured to contemporaneously handle 
5 multiple requests, e.g., determine (308) the relevant context 
information sources 202 for a number of users at the same 
time. The rules engine 208 processes the rules set using a 
Rete algorithm to determine (308) the relevant context 
information sources 202, although the rules engine 208 may use 

10 any algorithm. The Rete algorithm uses a tree format to match 
various items based on a series of decisions made at a number 
of nodes in the tree. . The rules engine 208 uses the rules. 206 
in the rules set as tree nodes. Paths through the various 
nodes end in a determination (308) of what context information 

15 sources 202 relate to the event. In a simplified example, if 

the event relates to a traffic problem at the intersection of 

i 

U.S. Route 2.6 and Interstate 405 in Portland, Oregon that is 
expected to clear in two hours, the rules engine 208 could 
determine relevant context information sources 202 as 
20 including the user's physical location, mobility status, 

current activity, and future activities. The rules engine 208 
informs the context aggregator 212 to query these context 
information sources 202 in determining the user's context. 
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Once the rules engine 212 determines (308) the relevant 
context information sources 202, the rules engine 208 sends an 
indication of the relevant context information sources 202 to 
the context aggregator 212- The context aggregator 212 scans 
5 (314) the relevant context information sources 202 for context 
information relevant to the event and collects (316) the 
relevant context information. This scanning (314) and 
collecting (316) includes consulting the user profile 204 
and/or the rules 206 (through the rules engine 208) . The 
10 context aggregator 212 sends the collected information to the 
rules engine 208 with the rules set(s) to use in processing 
the information. Some examples of the rules 206 in the rules 
sets include: 


if the location information is stale (older than x 


15 


minutes) then use the user's calendar to determine 


the user's location; 


• if the location information is from a GPS, then 


associate an accuracy of one hundred meters (or any 


distance measure) to the location; 


20 


• if the location information is provided bya 


wireless carrier associated with the user's 


communications device 110 then associate an 


accuracy of ten meters to the location; 
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• if the location information is from a differential 
GPS then associate an accuracy of five meters to 
the location; 

• using any of the above rules to determine speed 
5 and/or direction and the accuracy of the 

speed/direction; 

• if the location accuracy is high (less than five 
meters) then find one zip code and time zone for 
the user; 

10 • if the location accuracy is medium (between five 

and fifty meters) then use a radius to determine 
zip codes and time zones; 

• if speed and direction are steady for a period of t 
seconds then associate a confidence, e.g., high, 

15 medium, or low, with whether the user is moving; 

| • if new email is from a contact having relationship 

i 

k with the user, e.g., spouse, boss, peer, child, 
etc., then mark the email with an importance, e.g., 
high, medium, or low; 
20 • if the user is in a meeting with his/her boss then 

mark disposition as unavailable for low and medium 
priority email; 
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• if the user is on an airplane then mark disposition 
as unavailable; 

• if the time of day is night, e.g., past 9:00pm 
local time, then set disposition as unavailable, for 

5 low and medium priority email; 

• if the time of day is sleep time, e.g., past' 
10:00pm local time, then set disposition as 
unavailable; 

• if the event is flight related, e.g., flight 

10 cancelled, delayed, or rerouted, then use the user 

profile 204. to determine contacts that need to be 
notified; and 

• if a meeting is cancelled then analyze and 
prioritize the top n items in the user' s to-do 

15 list. 

In the traffic problem example above, collected relevant 
context information could include that the user is: 

• in a meeting at a particular location at work; 

• accessible by pager and cellular phone; 

20 • stationary in a wireless cell site twenty-four; 

and 

• scheduled to be at work for the next four hours. 

- 14 - 
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Preferably, the context aggregator 212 can collect (316) 
context information on the user' s location because location 
may dominate a user's context. For example, the user may be 
at a movie or giving a speech at a business conference and not 
5 want any communications. In determining a user's location 

from the relevant context information, the context aggregator 
212 preferably collects (316) location information according 
to this hierarchy, from most accurate and desirable to the 
least: latitude/longitude coordinates from a global 

10 positioning system, zip code, calendar, or other context 
information source 202. The context aggregator also can 
collect (316) any location information available in . the user 
profile 204 or relevant context information source 202. 

After collecting (316) the relevant context information, 

15 the context aggregator 212 analyzes (318) the relevant context 
information and generates (320) a composite context that 
defines the user's probable context. Analyzing (318) the 
relevant context information includes adding semantics to the 
relevant context information such as key words usable by the 

20 server 104. The context aggregator analysis also includes 

examining the relevant context information to see if the event 

is not relevant to the user in light of the relevant context 

information, preferably through the rules engine 208. For 
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example, in the traffic example above, the context aggregator 

212 may consider that the user prefers contact by pager from 

the user profile 204, but decide that the event is not 

relevant because the user will be at work until after the 

traffic problem is expected to clear. Thus, the context 

aggregator 212 ignores the event based on the user's current 

and future context and the process 300 ends (306) . If, 

however, the user was scheduled to leave work in an hour and 

travel in an area including the location of the traffic 

problem, the context aggregator 212 generates (320) the 

composite context. 

Generating (320) the composite context includes 

consulting the user profile 204 and the rules 206 (through the 

rules engine 208) . For example, if the context aggregator 212 

collects (316) location information from the user's calendar, 

the context aggregator 212 can use historical context 

information in the user profile 204 to predict the user's 

location using one or more rules 206. Using historical 

context information allows the context generation to be 

adaptive over time. Alternatively or in addition, the context 

aggregator 212 may consult the rules 206 to take the 

incomplete or stale location information and make a best guess 

as to the user's location. This prediction feature can be 
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applied to any of the relevant context information. In 
generating (320) the composite context, the context aggregator 
212 can prioritize the events and include the priority of when 
to send each event to the user based on the analysis of the 
5 context information sources 202, For example, an event 

currently occurring or an event occurring in two hours can 
take priority over an event occurring in six hours. 

Once generated (320), the context aggregator 212 provides 
(322) the composite context, preferably in extensible markup 

10 language (XML) , to the server 104 (or the mechanism associated 
with the server) . The server 104 (or the mechanism) can then 
send the event to one or more of the user's communications 
devices 110, and then the process 300 ends (306) . 

Other embodiments are within the scope of the following 

15 claims - 

1 

i 
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What is claimed is: 

1. A method comprising: 

determining the relevance of an event to a user based on 
service choices of the user; 
5 determining the relevance of information sources to the 

event, the information sources including at least data 
indicating a real-time status of the user; and 

determining whether to send information about the event 
to the user based on the information sources. 

10 2. The method of claim 1 in which the service choices 

include categories of events that interest the user. 

3. The method of claim 1 in which the real-time status 
includes location information. 

4. The method of claim 1 in which the real-time status 
15 includes mobility status of the user. 

5. The method of claim 1 in which the information 
sources also include data indicating the future status of the 
user. 
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6. The method of claim 1 further comprising receiving 
notice of the event, 

7. The method of claim 1 further comprising determining 
a communications device associated with the user to send the 
information about the event. 

8 . The method of claim 1 in which determining whether 
to send information to the user includes estimating the real- 
time status of the user based at least in part on the relevant 
information sources. 

9. The method of claim 1 further comprising determining 
when to send the information about the event to the user. 

10. The method of claim 1 in which the event includes at 
least one of weather conditions, traffic conditions, breaking 
news, travel information, receipt of electronic mail, and 
personal reminders. 

11. An article comprising a computer-readable medium 
which stores computer-executable instructions, the 
instructions causing a computer to: 

determine the relevance of an event to a user based on 
service choices of the user; 


determine the relevance of information sources to the 
event, the information sources including at least data 
indicating a real-time status of the user; 

determine a context of the user based on the relevant 
5 information sources; and 

determine whether to send information about the event to 
the user based on the context. 

12. The article of claim 11 in which the service choices 
include categories of events that interest the user. 

10 13. The article of claim 11 in which the real-time 

status includes location information. 

14. The article of claim 11 in which the real-time 
status includes mobility status of the user. 

15. The article of claim 11 in which the information 
15 sources also include data indicating future status of the 

user. 

16. The article of claim 11 further causing a computer 
to receive notice of the event. 
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17. The article of claim 11 further causing a computer 
to determine a communications device to send the information 
about the event. 

18. The article of claim 11 further causing a computer 
to estimate the context of the user based at least in part on 
the relevant information sources. 

19. The article of claim 11 in which the event includes 
at least one of weather conditions, traffic conditions, 
breaking news, travel information, receipt of electronic mail, 
and personal reminders. 

20. A system comprising: 

a server configured to connect to a network and to have 
access to service choices and to status information, including 
real-time status information, relevant to a user; and 

^ a mechanism included in the server and configured to 
determine the relevance of an event to the user using the 
status information and to determine whether to send 
information about the event to the user based at least in part 
on the service choices and the status information. 

21. The system of claim 20 in which the network includes 
the Internet. 
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22. The system of claim 20 further comprising a second 
communications device configured to receive the information 
sent to the user. 

23. The system of claim 20 in which the server is also 
configured to send the information to the user. 

24. The system of claim 20 in which the server is also 
configured to receive notice of the event and to provide 
information about the event to the mechanism. 

25. The system of claim 20 in which the mechanism is 
also configured to determine when to send information about 
the event to the user based at least in part on the status 
information. 

26. The system of claim 20 in which the status 
information also includes future status information. 

27. A method comprising: 
receiving notice of an events- 
determining a context for each one of M users using at 

least one of N sets of information sources, each set 
corresponding to at least one of the users and each set 
indicating at least a real-time status of the corresponding 
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user or users; and 

determining whether to send information about the event 
to each user based on each user's respective context. 

28. The method of claim 27 further comprising: 
5 determining the relevance of the event to each user using 

K sets of service choices, each set of service choices 
corresponding to at least one user; and 

determining the context for a user only if the event is 
relevant to the user. 

10 29. The method of claim 27 in which determining the 

context for a user includes estimating the context of the user 
based at least in part on the set of information sources 
corresponding to the user. 

30. The method of claim 27 in which the information 

15 sources corresponding to a user or users indicates a future 

i 
t 

status of the user or users. 
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